1. Field of the Invention
The present application generally relates to the effective and efficient transitioning of a business model from one phase to the next phase and, more particularly, to a policy-driven approach which specifies how to phase out of an existing business process phase and how to migrate to the newer or next business process phase without loss of critical data or metrics.
2. Background Description
In order to function effectively in today's business environment, organizations must have visibility in their business activities and operation performance at all times. This allows them to stay competitive and profitable. Business Performance Management (BPM) is a new generation of enterprise data management that focuses on monitoring business operations. BPM solutions must be able to efficiently process business events, compute business metrics, detect business situations, and provide the real-time visibility of Key Performance Indicators (KPIs). A BPM solution lifecycle involves five steps, as illustrated in FIG. 1:                1. A BPM solution lifecycle starts with modeling BPM solution. We define an observation model to be an abstraction of an observation system, which captures the requirements of BPM solutions. In an observation model, a collection of metrics is defined to measure the performance of business operations, where the computation of metrics is declaratively defined.        2. In the deployment phase, after performing a series of transformations and processing with an observation model, the executable code is generated and then deployed into the runtime platform.        3. Once the BPM runtime component is deployed, it monitors business activities by measuring metrics and detecting business situations.        4. In the next phase, the monitoring results are used to perform further analysis, for example, what-if or root-cause analysis.        5. The final phase is taking action for improving the business performance. The action may include change business processes and the like.The goal of each lifecycle is to improve the business performance, and by continuing lifecycle, the business performance is continually improved. In particular, when business performance improvement action is taken, one lifecycle is completed and another lifecycle is started. In the new lifecycle, a new observation model needs to be developed. When the new BPM solution is deployed, the evolution from the existing BPM solution to the newer one is required.        
A naive evolution mechanism is “hot swap”, i.e., when the new solution is deployed, the existing solution is forced to shutdown. Such an approach is easy to implement; however, it is not sufficient for supporting continual BPM lifecycles. First, the hot swap evolution may lead to information lost. The BPM is an event-driven stateful system, wherein business solutions are detected based on occurrences of events and the status of context instances. When a solution is forced to shutdown manually, the business situation detection that may be still in process is interrupted, which may eventually result in missing the situation. Second, the hot swap is not practical in some business scenarios. In some cases, the existing and new BPM solutions need to be running coexisting for a period of time, where the transition from the existing BPM solution to the newer one should be performed. For example, a BPM solution is developed and deployed to monitor a business process. Later on, based on the monitoring results and analysis of the BPM, the action that re-engineers business processes is taken. Therefore, the old process needs to be migrated to the new process. Accordingly, when a new BPM solution that monitors the new process is developed and deployed, the evolution of BPM solutions needs to be synchronized with business process migration. Thus, other than hot swap, transition based evolution is required.